In #722, ArraySequence tests generate ndarray.resize failures similar to #719, when running ArraySequence._resize_data_to(). Apparently the combination of Python 3.7 and coverage produce a ghost reference.

In this case, it's not clear that it's being called in a safe way such that we should skip reference checks. I added a test that shows that pulling a slice for use is sufficient to create a reference that causes extension to fail. This seems to be a case where we don't want to skip the refcheck, as a resize that increases the array size will typically release the original memory, corrupting data that users would expect to be unchanged.

The obvious solution is to switch to np.resize here, but np.resize returns views on an inaccessible object, so they don't have the OWNDATA flag, which means we can no longer use ndarray.resize in ArraySequence.shrink_data. A possible remedy is using np.resize().copy(), which will give us back control, and count on the garbage collector to take care of things, but until it does, we'll be seeing 3 copies of a single data array. This is in contrast to ndarray.resize, which uses realloc under the hood, so is pretty close to 1 copy.

Here I add a _safe_resize helper function. Because we can guarantee the second ndarray.resize will work, the intermediate a will be deallocated by realloc, not the garbage collector. This will also continue to have the current memory profile, if nobody ever tries to slice the data and then extend (which seems to be the case, as we haven't had any bug reports).

@MarcCote If you get some time, would you mind reviewing this? Or anyone else who feels comfortable.